[レポート] re:Inforce 2022 – Getting more out of your service control policies, featuring Morgan Stanley (IAM202) #reInforce

#セッションレポート

#AWS

杉金晋

2022.09.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさんこんにちは、杉金です。
AWS re:Inforce 2022 セッション動画の視聴レポートです。SCPに関するセッション動画で、モルガン・スタンレー社によるSCPのベストプラクティスは必見です！実際のセッション動画では分かりやすい図であったり、詳細な説明をしてくださっていますので、レポートを読んで興味を持たれた方はぜひ動画をご覧ください。

セッション情報

セッション動画

セッション概要

In this session, learn how to use service control policies (SCPs) to allow your builders to innovate on AWS while staying within your organization’s security guidelines. By using SCPs effectively, you can help establish guardrails for your teams so that they can focus on innovating for your business. Learn about the basics of SCPs, situations where you can use them, how to test and roll them out across your AWS Organizations environment efficiently, and the top SCPs recommended for virtually everyone. (IAM202)

スピーカー

Swara Gandhiさん
- Solutions Architect, Amazon Web Services
Itay Cohaiさん
- Executive Director, Morgan Stanley
Zulfi Haiderさん
- Vice President, Morgan Stanley

レポート

アジェンダ

Overview of service control policies (SCPs)
Using SCPs effectively
Getting the most out of your SCPs
Our top 5 recommended SCPs
Morgan Stanley AWS organization/SCP evolution
Lessons learned
Use cases

Overview of service control policies (SCPs)

Set preventive guardrails with SCPs

ワークロードが増加し、ビジネスで使用するAWSアカウント数が増えるにつれて、所有するすべてのアカウントに適用できる集中制御の仕組みが必要となる。SCPはAWSが提供するツールの1つで、プリンシパルが組織内で何ができるかを制御するためのもの。あるアカウントのエンティティは明示的にアクセス権を与えない限り、別のアカウントのエンティティにアクセスできない。SCPはOrganization（組織）のどのレベルにも適用できるが、幅広く適用することを検討すること。SCPはアクセスを許可するものではなく、あくまでガードレールである。

SCPs define maximum allowable permissions

アクセスを許可するポリシーは2種類ある。

IDベースのポリシー
リソースベースのポリシー

IDベースのポリシーはIAMプリンシパルに適用するポリシーで、リソースベースのポリシーはS3バケットやSNSキューなどのリソースに適用するもの。IDベースのポリシーやリソースベースのポリシーによって、実際にS3バケットを作成したり、SNSキューを作成する。ポリシーによって利用者にアクセス権限を与えている。

SCPの場合はガードレールでアクセスを許可することはできない。最大限の権限を定義するだけである。従って、組織でこれら上記2種類のポリシーとSCPの3つすべてを実装している場合、有効な許可はこれら3つの組み合わせ結果である。あるアクションが3つすべてで許可されていれば、そのアクセスは機能する。

SCPs apply to your principals

SCPはプリンシパル、つまり組織が所有するIAMプリンシパルのみ適用される。例では2つのアカウント（アカウントA、アカウントB）があり、両方とも同じひとつの組織単位（OU）に所属している。S3バケットへのアクセスをTLS接続のみ受け入れたいとする。その場合、以下のポリシーを定義する。

"Effect": "Deny",
"Action": "s3:*",
"Resource": "*",
"Condition": {
    "Bool": {
        "aws:SecureTransport": "false"
    }
}

このポリシーは、SecureTransportがfalseであれば全てのS3のアクションを拒否することを表す。このSCPをOUに適用する。アカウントAにIAMロールを作成し、アカウントBにあるS3バケットのオブジェクトにHTTPでアクセスしようとしている。バケットやロールに付けられたポリシーはパーミッションが与えられていると仮定する。この場合どうなるか。OUにSCPを適用していることに注目してほしい。このロールは組織に所属しているため、アクセスは拒否される。アカウントAはOUに所属しており、OUにはSCPが適用されている。IAMロールが組織内に存在していることが重要である。

今度はその逆で、IAMロールが組織に存在しない場合を見てみる。組織にアカウントが1つしかないとする。これをアカウントBとして、アカウントにオブジェクトの入ったS3バケットを用意する。先ほどと同様の以下のSCPを同じOUに適用する。

"Effect": "Deny",
"Action": "s3:*",
"Resource": "*",
"Condition": {
    "Bool": {
        "aws:SecureTransport": "false"
    }
}

組織外からのクロスアカウントアクセスのケースを考える。クロスアカウントアクセスを許可する場合、両方（アクセス元AWSアカウントとアクセス先AWSアカウント）にポリシーが必要となる。アクセス先であるS3バケットのポリシーを以下に設定する。

"Effect": "Allow",
"Principal": {
    "AWS": "arn:aws:iam:ExternalAccount:role/RoleC",
    "Action": "s3:*",
    "Resource": [
        "arn:aws:s3:::workload-B-Bucket/*",
        "arn:aws:s3:::workload-B-Bucket"
  ]
}

組織外部のAWSアカウントから入っていくるIAMロールCが「workload-B-Bucket」に対して任意のS3アクションを実行できるポリシーである。次にアクセス元の組織外部のAWSアカウントにIAMロール「RoleC」を用意する。RoleCのポリシーにも「workload-B-Bucket」に対するアクセスを許可するように以下のポリシーを設定する。

"Effect": "Allow",
"Action": "s3:*",
"Resource": [
      "arn:aws:s3:::workload-B-Bucket/*",
      "arn:aws:s3:::workload-B-Bucket"
]

SCPが適用されていることを考慮して、RoleCからworkload-B-BucketにHTTPでアクセスを試みると結果はどうなるか？
この場合、アクセスは許可される。スライドのタイトルにある「SCPs apply to your principals」にある通り、SCPは本人しか適用されない。それでは、どのように回避するのか。

Restrict external principals using resource policy

このようなアクセスを拒否するポリシーを実装したい場合は、SCPではなく、リソースポリシーレベルで実装する必要がある。

"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
        "arn:aws:s3:::workload-B-Bucket/*",
        "arn:aws:s3:::workload-B-Bucket"
    ],
    "Condition": {
        "Bool": {
            "aws:SecureTransport": "false"
    }
}

RoleCは組織の一員ではないため、SCPは適用されない。アクセスはIDベースのポリシーとリソースベースのポリシーに依存する。

Using SCPs effectively

Use the right guardrail for the right controls

SCPの効果的な使い方として、以下の3つについて話をする。

SCP
Permission boundary
Session policy

3つともガードレールポリシーで、アクセス権を与えものではなく許容される最大限のパーミッションを定義する。それぞれの影響範囲は異なる。SCPは、ルートレベルで適用した場合は組織内のすべてのアカウントに適用され、OUに適用した場合はアカウントグループに適用される。Permissions boundaryは、特定のプリンシパルにのみ適用される。もし、ある特定のIAMロールに対して権限の制限を行いたいのであれば、SCPではなくPermissions boundaryを使用する。セッションポリシーは、セッションに適用されるスコープダウンポリシーである。AWSアカウントで特定のアクションを実行するIAMロールに用いられ、その場でセッションポリシーを渡すことができる。一般的なポリシーがあり、誰かがS3へのアクセスのみを必要とした場合、S3だけを許可してその他すべてを許可しない。特定の役割に適した権限を持つことができる。影響範囲や拡張性を考慮して3つを使い分ける。

Getting the most out of your SCPs

実際にどのようなコントロールがSCPに含まれるべきか。SCPの書き方、最大限に活用するためのテクニックについて説明する。

1つ目のテクニック：継承を利用する
2つ目のテクニック：ポリシーを組み合わせる
3つ目のテクニック：ポリシーをコンパクトにする

Take advantage of inheritance for Deny

1つ目のテクニックは継承を利用することである。重要なポイントは、Denyのために継承を活用することである。組織内のSCPは、許可するポリシーと拒否するポリシーのどちらかを持つことができる。例えば、Denyがある場合にそれがそのまま連鎖的に継承される。Rootで拒否ポリシーを適用すると、配下に作成されたOUとアカウントに継承される。Rootレベルで許可ポリシーが設定されている場合、暗黙の了解はないため、OUおよびアカウントで許可する必要がある。

例を見てみる。アカウントAとアカウントBが同一の組織、OUに所属する。組織のRootに以下のポリシーを適用する。

{
  "Version": "2012-10-17",
  "Statement":[
      {
          "Sid": "ApprowvedServiceOnly",
          "Effect": "Deny",
          "Action": [
              "robomaker:*",
              "iot:*"
          ],
      "Resource":"*"
    }
  ]
}

組織のRootにRoboMakerとIoTサービスを拒否するポリシーがある。OUに、以下の異なるSCPを適用する。

{
    "Version": "2012-10-17",
    "Statement":[
      {
          "Sid": "serverlessonly",
          "Effect": "Deny",
          "Action": "ec2:RunInstances",
          "Resource":"*"
      }
   ]
}

OUに所属するアカウントは拒否をすべて継承する。アカウントAやアカウントBでは、ロボメーカーIoTサービスを利用することはできず、EC2 RunInstancesも実行できない。Denyは適用する場所によって継承される。

Combine policies

2つ目のテクニックは、ポリシーを組み合わせることである。組織内の各レベルで適用できるポリシー（SCP）の最大数は5つである。Rootレベル、OUレベル、アカウントレベルで5つのポリシーを持つことができる。そのため、複数のポリシーを組み合わせる必要がある。
SCPを使い始めるときは、フルアクセスポリシーで始まる。すべての利用者がフルアクセスできることを意味するものではない。SCPレベルのガードレールがなく、IAMに頼っているということに過ぎない。

2つのポリシーを組み合わせる例を挙げる。まず、1つ目のポリシーを以下とする。

AWS full access policy

{
    "Version": "2012-10-17",
    "Statement":[
      {
          "Effect": "Allow",
          "Action": "*",
          "Resource":"*"
      }
   ]
}

2つ目のポリシーは、S3とSecurity Hubの拒否を含むものである。

{
    "Version": "2012-10-17",
    "Statement":[
      {
          "Effect": "Deny",
          "Action": "s3:DeleteBucket",
          "Resource":"*"
      },
      {
          "Effect": "Deny",
          "Action": "securityhub:Disable*",
          "Resource":"*"
      }
   ]
}

この2つのポリシーを組み合わせると次のようなポリシーとなる。

{
    "Version": "2012-10-17",
    "Statement":[
      {
          "Effect": "Allow",
          "Action": "*",
          "Resource":"*"
      },
      {
          "Effect": "Deny",
          "Action": [
                "s3:DeleteBucket",
                "securityhub:Disable*"
            ],
          "Resource":"*"
      }
   ]
}

組み合わせることでポリシーの数を節約できる。ただし、期待している意図と変わらないことに注意すべきである。

Compact your policy

3つ目のテクニックは、ポリシーのコンパクト化である。コンパクトにするための方法は3つある。

Use AWS Management Console
Remove white spaces
Shorten:"Sid"

SCPの最大サイズは5,120byteである。マネジメントコンソールを使用している場合は、ポリシーを保存する際にスペースを自動的に削除する。CodePipelineを使用してSCPをデプロイする場合は、CICDパイプラインでスペース削除を実装する。

SIDはステートメントIDのことで、任意の項目である。特定のポリシーが何をするものなのか等のリファレンスを入れるのに使える。ポリシーのサイズが足りなくなったら、SIDを削除するか、短くするとよい。もしくはSCPをデプロイする前にコードから取り除く方法もある。

Our top 5 recommended SCPs

Prevent leaving the organization

（本記事最後の方にあるResourcesにて各SCPのリンクを記載しています）

1つ目は、組織からの離脱を防ぐことである。SCPを適用する場合、組織内のすべてのアカウントが組織の一部である必要があり、その場合のみSCPが適用される。そのため、組織から離脱するアカウントを拒否するポリシーを適用する。組織にはメリットがある。一括請求や割引、異なるアカウント間で環境のセキュリティと監査を一元的に行える。そして、SCPを使用して中央制御を実装できる。

Only allow usage of approved AWS Regions

2つ目は、承認されたAWSリージョンのみを使用することである。AWSでは、リソースを作成したい場所をグローバルに選べるが、一部地域のみで事業を展開している企業にはコンプライアンスの必要性がある。その場合に利用可能なリージョンを制限する。リージョン制限から除外したいグローバルサービスは、NotAction条件を利用する。

Prevent usage of the root user

3つ目は、rootユーザーの使用を禁止することである。rootユーザーの使用を必要とするタスクは、実際にはごくわずかである。ルートユーザーの使用を拒否するポリシーを適用すること。

Prevent disabling security services

4つ目は、組織内のセキュリティサービスを無効化しないことである。CloudTrail, Config, Security Hubで拒否するアクション例を挙げる。

AWS CloudTrail
- cloudtrail:DeleteTrail
- cloudtrail:PutEventSelectors
- cloudtrail:StopLOgging
- cloudtrail:UpdateTrail
AWS Config
- config:DeleteConfiguration*
- config:DeleteDeliverryChannel
- config:DeleteRetention*
- config:PutConfiguration*
- config:PutDeliveryChannel
- config:PutRetention*
- config:StopConfiguration*
AWS Security Hub
- securityhub:Disable*
- securityhub:DIssociate*
- securityhub:DeleteInvitations
- securityhub:DeleteMembers

もし、これらのサービスや他のセキュリティサービスを使用している場合は、サービスの無効化を拒否するSCPが必要である。

Protect your sensitive Amazon S3 buckets

5つ目は、センシティブなS3バケットに対する操作を防止する。本番用のS3バケットに機密データが保管されているとする。組織内の誰にもS3バケットを削除したり、S3バケットの公開アクセス設定を変更したり、S3バケット内の画像やオブジェクトを削除する権限を与えたくはない。その場合に関連するアクションを拒否してS3バケットを保護する。

Specific S3 bucket deletion
- s3:DeleteBucket
- s3:DeleteBucketPolicy
S3 public access settings
- s3:PutAccountPublicAccessBlock
- s3:PutBucketPublicAccessBlock
- s3:PutObjectVersionAcl
- s3:PutObjectAcl
Object and version deletion
- s3:DeleteObject
- s3:DeleteObjectVersion
- s3:DeleteObjectTagging
- s3:DeleteObjectVersionTagging
- s3:PutLifecycleConfiguration

Morgan Stanley AWS organization/SCP evolution

モルガン・スタンレーは、グローバルな金融機関である。セキュリティとコンプライアンス、そしてお客様のデータ保護に深く配慮しているからこそ、SCPの導入に踏み切った。OrganizationsとSCP利用の道のりについて少し話をする。

取り組み始めた当初は、AWS Organizationsの構成は自分たちの組織図をコピーしたような作りにした。これは、これまでLDAPで行ってきたようことと同じような方法である。部門があり、部門によって利用するかを決める。それが理にかなっていると信じていた。

Then comes a re-org

組織再編、それは大きな組織ではよくある。A部門はA++部門に名前が変わり、B部門はC部門に統合される。D部門は存在しなくなった。組織再編によって、Organizationsの構成として間違った道を歩んでしまったことに気づいた。

学んだ教訓
- OUは、頻繁に変更されないものをベースとすること
- OUは、人事構造ではなく技術的なコントロールに基づくものでなければならない

私たちがやったようなことをしないように。実際の組織に基づいてOrganizationsを構成しないようにすること。会社の組織構造は変わるのである。時間と共に変化するものに合わせないこと。それより技術的なコントロールに合わせる方がよい。インターネットへの公開度合いやセキュリティポリシーに基づいてワークロードをグループ化したり、地域や同じワークロードに対応するサービス群に基づいてグループ化することもできる。

That's how we deployed deny policies

組織図に基づくとビジネスユニットやOUによってポリシーは当然異なる。AというOUではデータベースを使用禁止、BというOUではLambdaを使用禁止にする。人事部、経理部、請求書発行部などのサブ部門についても検討した。その結果、何が起こったか。

Then comes troubleshooting

利用者から「アクセスが拒否された、利用できない」という問い合わせを受けることがある。ごく一般的な話で、できないはずがない。どこで制御されているSCPかを確認しようとした。幸いなことにSCPで何かが拒否された場合、少なくともエラーメッセージにSCPで拒否されていることが分かる。しかしアカウント、OU、Rootレベルのどこに適用されているSCPか、すべてを片っ端から確認する必要があった。

学んだ教訓（拒否の方針を次のようにする）
- Single layer
- Immutable
- Highly guarded

1つ目のポイントは、すべての方にお勧めする。SCPは一箇所で管理されていれば、見なくてもどこに何があるかがわかる。
2つ目のポイントは「不変性」で、SCPが変更されないようにする。Rootアカウントを使うべきときに、ポリシーを付けたり外したりするのは、良いポリシーとは言えない。何かをするためにセキュリティポリシーを変更したい場合は、アカウントを他のOUに移動すべき。ルートが許可されるステージングエリアを用意する。そこに移動して、そこで作業をして、終わったらまた移動する。そうすることで、ポリシーを付けたり外したりする必要がない。庭に柵があって、柵を撤去したり再び設置したりしないのと同じ理屈である。2つ目のポイントの側面として、コードの不変性についても話をする。SCPは手作業で編集してはいけない。SCPはコードとして成果物として管理されるべきである。デプロイのパイプラインを構築するために、実際に役立つツールとしてのインフラは十分にある。
そして、それが3つ目のポイントへとつながっていく。SCPは重要な防衛線の一つであることは間違いないが、ガードできない。SCPが1つの場所にあり、コードとして維持されているならばモニタリングすべき。リポジトリにあるSCPのコードと実際に適用されているSCPが同じあることを監視すべきである。

And then we run out of policy space

学んだ教訓（Denyポリシーは）
- 少なく
- よりシンプル
- 粒度を粗く

拒否のポリシーが細かすぎる or 長すぎる場合、SCPにはふわしくない。
　　　
SCPには5Kのサイズ制限がある。すべてをSCPに置き換えたことで、ポリシーが肥大化していった。同じ目的であってもポリシー1がポリシー2に変わっていく。すべてのアクセス制御がSCPである必要はない。先ほどの説明にあったようにリソースベースのポリシーやIAMに設定することも可能である。permissions boundaryに記載することも可能である。また、Infrastructure as codeを使って、インフラのコードテンプレートに焼き付けることができる。TerraformモジュールやCloudFormationスタックを使用しているかどうかに関わらず、この制御を簡単に組み込むことができる。

SCPは常に私たちを守ってくれるわけではないため、SCPはできるだけ粒度を粗くする。
セキュリティ設計の原則「Economy of Mechanism」を重視する。

（執筆者メモ参考:セキュリティ設計の原則「Economy of Mechanism」について）

さて、このような旅と進化を経て、私たちがたどり着いたのは、このようなものである。

（スライドの図にて変更後のOU構成を説明:文章での説明が難しいため割愛します）

Enforcing out guardrails

管理アカウントと拒否ポリシーに少し焦点を当てましょう。これらは、ルートで持っている拒否のポリシーの一部である。

GuardRail-Deny-non-operating-Regions(Deny actions outside the authorized AWS regions)
GuardRail-Deny-exFilltration(Deny ability to store / upload to Data sources outside the org-id)
GUardRail-ThouShallNot(Deny actions that violate key security and operational controls)
GuardRail-Restrics-OUs(Deny actions no authorized for the parent OU)

1つ目は、先ほども発表したもので利用するリージョンを限定するものである。金融業界では様々なコンプライアンス上の理由から非常に重要である。ほとんどの業界では、欧州のGDPRであろうと、HIPAAであろうと、どの地域にも類似のものがある。2つ目は、データ流出の拒否についてである。これは"aws:ResourceOrgID"を利用することで実現できる。後ほどの説明で焦点を当てる。3つ目は、やってはいけないことの一般的なSCPを指す。4つ目は、先ほどの説明にもあった外部からのアクセス制限で、"aws:ResourceOrgPaths"を使用する。後ほどの説明で深く説明する。

Organizing out Organizations deployment

先ほどパイプラインの話とSCPをコードとして管理する話をした。ここでは職務の分離に焦点を当てる。SCPを作成・デプロイするチームは、SCPを使うチームであってはならない。SCPをデプロイするSecOpsチームとアプリケーションをデプロイするDevOpsチームは異なるパイプラインを使用する。

SecOpsパイプライン

SCP in Source Control
Review Process
IaCによるSCPのデプロイ（AWS Organizationsにデプロイ）

DevOpsパイプライン

Infrastructure as Code
Review Process
IaCによるデプロイ（対象のAWSアカウントにデプロイ）

Use cases

SCPをどのように使うかについて、ユースケースとしてもう少し深く掘り下げて考える。

UC1:Organizations housekeeping

アカウントライフサイクルの全フェーズをコードで管理する。"CreateAccount "と "CloseAccount "の権限は、オートメーションプリンシパルのみが利用可能とする。人の手では、アカウントを作成や閉じることはできない
SCPのコンテンツをコードで展開する
私たちのOrganizationsは、招待制ではなく誕生制（アカウント作成）である
メンバーアカウントは組織から離れることができない/組織から削除できない
"LeaveOrganizaion","InviteAccountToOrganization","RemoveAccountFromOrganization"などのパーミッションは永久にブロック

組織を離れたり、組織から削除されたアカウントはSCPによるガードレールを回避するため、セキュリティ上のリスクが生じる。アカウント閉鎖の事故は運用に影響を及ぼす。どちらの操作もAWSコンソール上で簡単に2回クリックするだけで利用できるため、予防的なコントロールが必要である。

アカウント誕生制とは、組織に属するすべてのアカウントが、一貫したセキュリティのベースラインを使用して作成されたことを確認するためのものである。組織からアカウントを削除する権限は管理アカウントに存在し、SCPでは制御できないため、permissions boundaryによってブロックしている。permissions boundaryでブロックしているのは、ヒューマンプリンシパルによるアカウントを閉じる機能で、コードを通じてのみアカウントを閉じることができる。

UC2:We explicitly allow services per account

アカウントごとにサービスを明示的に許可する

AWSのサービスは日々増え続けている
アカウントレベルでのFullAWSAccessを付与しない
サービスを許可する前に、各サービスのセキュリティへの影響をレビューする時間を確保している
200以上あるサービスのうち、1つのアカウントで30以上のサービスを利用することは通常想定されない

すべてのサービスには攻撃対象がある。個々のサービスを理解した上で、許可ルールの中でそのサービスを許可すること

{
  "Sid": "AllowBaselineServices",
  "Effect": "Allow",
  "Action":[
    "billing:*",
    "cloudtrail:*",
    "cloudwatch:*",
    "config:*",
    "logs:*",
    "guardduty:*",
    "health;*",
    ....
  ],
  "Resource": "*"
}

上記ポリシーは、組織内のアカウントの種類に関係なく常に必要とされる基本サービスのセットを定義したポリシーである。

UC3:We use SCP to deny exfiltration

{
  "Sid": "DenyS3writesToUnauthorizeBuckets",
  "Effect": "Deny",
  "Action":[
    "s3:Put*"
    ],
  "Resource": "*",
  "Condition":{
    "StringNotEquals":{
      "aws:ResourceOrgID":"o-xxxxx"
    }
  }
}

VPC内から個人用S3バケットにデータをアップロードするためのブロックパス

データ流出に関するユースケースである。AWSの組織に属さないデータソースへのデータアップロードを拒否するために、"aws:ResourceOrgID"キーを利用する。このユースケースの具体的な実装の1つは、私たちの組織に属さないS3バケットへのアップロードを拒否することである。

UC4:Our guardrail policy attachments are immutable

What is immutable - Build once,　attach forever
ガードレールSCPはRootに恒久適用する
拒否ルール(Deny rules)は、組織全体のアクションを防止する。例外はない。
制限ルール(Strict rules)は、特定OUのアクションを制限するもの
条件キー "aws:PrincipalOrgPaths "を使用する
制限を除外するためには、SCPを切り離したり、SCPを変更したりする必要はなく、その制限を除外しているOUにアカウントを移動させる。OUのメンバーシップをルールに基づいて監視する。

OUメンバーシップを通じてSCPコントロールの変更に影響を与えることで、ポリシーアタッチメントを変更できないようにしながら柔軟性を持たせることができる。

UC5:We Disable all actions for Lock Ou

{
  "Sid": "Lock",
  "Effect": "Deny",
  "Action":"*",
  "Resource": "*",
  "Condition":{
    "ForAnyValue:StringEquals":{
      "aws:PrincipalOrgPaths":[
        "o-xxxxx/r-xx/",
        "o-xxxxx/r-xxx/ou-xxx-xxxxxxx/"
      ]
    }
  }
}

Conditionに指定しているのは、LockOUとRootのメンバーに対する拒否アクションで、アカウントに対するすべてのコントロールプレーンアクションを無効にする。

攻撃面を減らすということである。何百ものアカウントを扱う場合、アカウントに対するすべてのコントロールプレーンのアクションを無効にできる隔離場所が必要になる。例えば、廃止予定のアカウント、セキュリティ事故の調査のために隔離されたアカウント、すでに廃止され、その90日間に削除されるのを待っているアカウントなどである。アカウントをロックOUに移動させると、ガードレールSCPはアカウントに対するすべてのコントロールプレーンアクションを拒否するので、アカウントは実質的に麻痺状態になる。

ポリシー・ステートメントの"aws:PrincipalOrgPaths"に、RootのパスとLock OUのパスを記述している。ユーザーがルート直下にアカウントを作成することを抑制する。末尾のスラッシュに注目してほしい。この条件はサブOUのメンバーではなく、rootの直接のメンバーにのみ適用されることを意味する。

Morgan Stanley SCP best practices

5つのユースケースをご紹介した。最後にSCPに関して私たちが行っているベストプラクティスを紹介する。

Deny Policies are out guardrails. Attach guardrails to org root level

Allow Policies are our enclaves. Attach enclaves to leaf account level

Security Monitoring to assure leaf accounts do not attach FUllAWSAccess, and operational monitoring to assure OUs always attach FullAWSAccess

Separation of duty between managing organization versus the rest of the account

Key organization artifacts are managed by DevSecOps pipeline, rest of AWS managed by DevOps pipeline

Separation of entitlement between org management account and leaf accounts

Every new service allowed in enclaves follows a security review

OUs are our best friends for managing AWS account group restrictions

Guardrail policy immutably attached to org root and denies actions based on OU membership (aws:PrincipalOrgPaths)

Restrict Regions base on OUs

Put the unneeded accounts in LOCK OU

Only allow root login in a highly monitored OU

Resources

Blog:get more out of service control policies in a multi-account environment

Example service control policies to get started

Getting started with AWS Organizations

感想

AWSをどのように活用しているかという事例はいつも興味深い話が聞けていいなと思っているのですが、今回のモルガン・スタンレー社の事例はとても参考になりました。最後にこれが俺たちのベストプラクティスだ！って紹介しているのは素晴らしいですね。OrganizationsやSCPのより活用すべきヒントが得られました。re:inforce2022のレポートブログはこれが2本目で、1本目は箇条書きで書いたのですがスマホで見づらかったところが反省点でした。それを踏まえて深いレベルの箇条書きをなるべく無くしてみました。